WARNING: THIS IS A TEST

THIS DOES NOT CONTAIN NEW TYRE PHYSICS OR THE NEW GRAPHICS SYSTEM

PLEASE TEST BEFORE YOU POST

PLEASE... NO OFF TOPIC FEATURE REQUESTS!


Hello Racers,

Here is a new test patch: 0.7F6

Please read the list of changes below.

0.7F6 is COMPATIBLE with 0.7F

- You CAN connect online with 0.7F
- You CAN play single player replays from 0.7F

You should back up or rename your LFS.exe from version F so you can revert to it if necessary.


Changes in F6:

Force feedback:

Some steering wheels have a bug in their drivers, that cause them to seen as "First person controller" devices.
In this case, LFS does not know they are a steering wheel, so it does not enable the steering wheel bump stops.
There is a new option, in "Axes / FF" section to Enable steering wheel bump stops.
Do not use this if your controller is not a steering wheel.

VR:

It is possible for some VR headsets to have a FOV aspect ratio that is different from their pixel aspect ratio.
Until now, LFS did not deal with that case correctly, and this was apparent with the HTC Vive Pro 2.
Now, LFS uses the left, right, up, down FOV values more directly which should solve the problem.


Changes in F5:

InSim:

System to allow AI drivers to be directly controlled by a local InSim program.
Discussed here: https://www.lfs.net/forum/post/2114897#post2114897

AI drivers:

AI can now spawn in a config with an AI path even if knw has not been generated
FIX: AI now spawn in game with full fuel load if there is no path (or no knw)
FIX: Rare crash in AI code after another car spawned outside path


INSTALLATION:

Live for Speed LFS 0.7F must already be installed!

- Rename your old LFS.exe
- Copy the LFS.exe from this patch zip into your LFS folder

NOTE: You can see if the patch is correctly installed when you run LFS.
Check the version number at the bottom of the entry screen.


DOWNLOAD:

IF YOU ALREADY HAVE 0.7F:
PATCH 0.7F TO 0.7F6 (ZIP)
https://www.lfs.net/file_lfs.p ... e=LFS_PATCH_7F_TO_7F6.zip (1.1 MB)

Last edited by Scawen, Thu 20 Feb 2025, 16:29.

Right, first thing I had to do this morning was some essential maintenance (gutter clearing). The rain and hail brought more moss down.

I've had a bit of a fight with some php code but now the season signups are updated so admins of a league that is set to require approval of entries get a new email if:

1) There is a new entry
2) An entry that has been approved, is now edited

In case (2) the entry is no longer marked as 'approved'.

I've made it clearer to see on the admin pages if an entry requires approval.

I'll continue to look at more things now.


I know Viperakecske and some others will be frustrated that I'm not working on Tyre physics this afternoon but I'd really appreciate if they can keep out while I do a few more things this afternoon to make the league entry system good enough to be used for a high quality league. The idea will be to get on with the tyres in the morning. So please leave me in peace.

Well thank you very much and I hope I haven't been too annoying pressurising you to do it. I will look at some this morning and will keep supporting it as you go. For anyone concerned, this will not stop me working on the tyre physics this afternoon.

I understand it's an experiment and I thank you for making that experiment real.

EDIT: I'll do the country export of CSV as one of the first things and look at user-editing removing approved status, and sending an email to all admins when a change is made. Maybe, to avoid email spam, an email like that is only made, when an "approved" entry is edited and becomes no longer approved?

Last edited by Scawen, Mon 27 Jan 2025, 11:10.

Quote from Pukyy :

...as the updates that we find necessary are taking a longer time because of the focus on the cruise side of the game...

Total speculation and in fact complete rubbish.

People are free to suggest what they want and I will choose what I do and how to manage my time.

If other people will be deciding what I do I might as well go and get a job as a programmer and earn 5 times the salary.

I'd be grateful if community members wouldn't try to be self appointed LFS project managers.

I did one afternoon's work and a morning fixing it, on something that people have been waiting for, for longer than people have been waiting for tyre physics. This had no bearing at all on the completion of the tyre physics. Please avoid making up rubbish and allow people to make sensible suggestions if they wish to.

This is the LFS Programmer Forum.

In most cases it is probably best to not comment if you aren't a programmer. Otherwise I would have posted in General LFS Discussion or Test Patch forum.

I don't go and post my opinions in the quantum physics forums because I probably don't know what the **** I am talking about.

I don't want to get involved in a conversation but I'll say a few things then I'll unsubscribe from the thread.

Quote from Flame CZE :

I'm curious what progress Eric has made regarding the track updates and even the new tracks. Last report from him was in the 20th anniversary news article from 2022. Are the existing tracks fully updated now, or are there still some holes to fill? It would be nice to see some screenshots if there is something new to show.

I think Eric knows what I have been going through this year and probably didn't want to bother me with a progress report. And on the other hand he took on a pretty monumental task and so maybe he wanted it near complete before showing anything. I don't know really, I have not tried to discuss a progress report with him.

He did even more finishing of South City and has done repairs and updates on all the other tracks too. There's a curious thing about finishing things, as anyone knows who takes on big projects. The 'last few things' take a lot longer than expected.

But the biggest task he has been on for a long time, is Kyoto. Not only has the track had a lot of work done, but also the surrounding areas, it has had a treatment that could remind you of Westhill. I think he saw the potential and went for it. I'm sure you will be very happy to see a progress report about it when the time comes.

Quote from gu3st :

It also doesn't help that recently Scawen has needed to take more web development tasks on either. There's enough PHP knowledge in the community that I think a trusted group might be able to help directly or at least give some informed advice. I'm not really a PHP dev anymore (outside of some contract work on a popular livery sharing site), but I do have many many years of knowledge and expertise with web dev.

I just want to make it clear, I didn't start this year saying, "OK, now I will spend the first 7 months of the year doing web stuff that is out of my comfort zone". I didn't know at the start of the year that Victor would be more involved with his other job and gradually become more reluctant to work on Live for Speed.

The reality is I encountered a barrage of emergency situations (and growing problems) which needed attention. To list a few:

1) Mod hacks that were destroying the online experience
2) Mod submission spam that was overwhelming the reviewers
3) Bugs in mods system e.g. archives of deleted mods never being removed
4) Apparent leak of passwords that LFS users had given to a pirate website years ago
5) Bugs in hosting system causing crashes, slowdowns, etc.
6) DDoS attacks on web server
7) DDoS attacks on game servers

This is not a complete list, it's just off the top of my head. Each of these things took days or weeks to resolve, but at the start of each task I couldn't really delegate the task to community members. I just had to look into the issues and figure out what is going wrong, although the relevant systems were not written my me, and at the start of this year I really had no idea how it all worked. After figuring out the issue, either fix it (sometimes simple) or implement new systems as required (not usually simple).

I'm just explaining how one task after another has come my way, preventing me from doing whatever was planned, and this has sometimes been very frustrating, but it's not something that could be delegated to community members.

This new patch is intended to be a stable release. With all the fixes done, I hope that our systems may be stable for a while. This should let me focus on the tyre physics, to complete it to a good condition so it can possibly be released, along with some remaining graphical tasks. I can't give a time frame for this, as so far this year I've had almost no time to look into it. It seems like now I'm where I thought I would be at the start of January.

At least with all the delays on my side, Eric has had more time to do extra good work and keep up the detail. I have also learned a whole lot about PHP and SQL and understand how our web systems work. For example I was able to do this whole 0.7F update release alone without Victor's help.

Have you tried graphics options like:

Textures: low res
Texture filtering/AF: 1x

Misc options:

Full physics for remote cars: [no]

I think what you saw was down to 2 different things.

1) You saw damage on his car, but he did not. This could be that on your computer, damage was inflicted on his engine due to differences on your computer calculating the physics, compared with the 'real' case on his computer. Soon, some info came from his computer correcting the engine damage your computer had estimated too high.

2) Later, he and you had engine damage but the other could not see it. This could be due to granularity due to compressed data. Your engine health would have to be worse than 99.8% to be visible on a remote computer. But it only has to be worse than 99.95% to be visible on the local computer.

It's not because of the location of the object centre. That doesn't affect physics, but it does mean the setups are not interchangeable.

The editor cars have been updated to have realistic setups. I don't know the specifics, but maybe you could open two instances of LFS and look through side by side, to see what the changes are. That's the only way I would be able to tell you the changes.

If you replicated all the settings and confirm the wheel sizes have not changed then you should get the same handling. It's likely that rim width has decreased because most of the public LFS ones are unrealistic (long subject, watch the video if interested). But rim with in LFS doesn't affect much, probably just affects wheel heating a tiny amount over a long period.

Differences between current public version and versions set up for future release aren't something I will get involved in or take an interest in.

Thanks, I decided not to add that one as it is not available in the new physics version.

No, I'm not a perfectionist.

I just want to release something that will be fun and not containing extreme flaws that would destroy racing altogether. No, I will not expand on this comment. I need to spend some peaceful time focused on the tyre physics, to understand exactly what is good and bad about it.

I'd like to get back to the tyre physics so we can get something released, although LFS will never be finished or perfect.

Unfortunately I have not yet worked even one hour this year on the tyre physics as I've been dealing with mod stuff most of the time. There were too many holes in the system and people were exploiting every crack. I hope that is coming to an end now with various improvements.

The mods system is simultaneously the best and worst thing ever to have happened to LFS.

The idea is to release a new version hopefully in a week or two (just like the current test patch with a couple more updates) then I can get back to work on the new version. So basically at start of April I'll be in the position I wanted to be at start of January.

OK, I've done a fix for the replay slider + MCI disconnect issue in Test Patch E8.

Now, when clicking on replay slider or using IS_RIP to do the same thing, NLP/MCI packets will not be sent. I hope this works because I haven't actually tested it, but it was just a line of code.

In the case when using IS_RIP with option RIPOPT_FULL_PHYS the NLP/MCI packets are still sent. My hope is that because it is taking the time to do the physics, the rate of MCI output may be manageable. But I haven't tested this at all so I can't really confirm.


About the similar issue when joining a server, I couldn't think of a quick way to safely avoid sending the packets until LFS catches up with the server. I want to consider this a bit longer.

OK, I'll describe that but first I will mention that saving is only in the graphical render code, not the physics.

The thing about tyres is as they are flexible objects, their vertices cannot simply reside on the graphics card memory. They must be calculated every frame and the vertices are sent from the CPU to the GPU each time. I had thought before the main cost was actually transferring the vertices to the graphics card, and calculating the normals of each vertex. But what I found was the worst part was calculating the colour of each vertex (according to its lighting condition and the sun highlight). This used a lot of integer maths and I found the CPU use was way less when I bypassed this function, returning a simple grey colour. So I set about converting it to floating point maths.

The general idea is that integer maths is good for adding and subtracting, but floating point is better when there is a lot of multiplying involved. There's some leftover integer maths in LFS left over from earlier times. Considering some of its code goes back around 30 years, when we had 486 processors, I worked at Digital Integration on the Hind Helicopter Simulator, Pentium was the latest super CPU and there were no 3D cards.

By converting to floating point I found it was instantly faster, so I changed the code some more so that the normals were calculated in floating point, actually borrowing some code from the development version, where this was done already.

In the development version, the tyre lighting is actually done on the GPU, based on material properties, but the vertex normals are still sent to the graphics card each frame. You can see it in the LFS Editor.

The older code (before Friday) had a lot of complicated stuff to avoid sending vertices if they were not needed. This was done by checking if a triangle faced the user's view before drawing it, then calculating vertices as needed. But that is way complicated. It's better, if possible to just calculate all the vertices then send them all, without jumping around between triangle and vertex code. But for quite a while the "avoid sending unnecessary vertices" was still winning. But eventually I got the vertex normal and lighting calculations fast enough that it was better to do it the simpler way and I saw best results in the profiler that way.

Unfortunately that work, that took most of a day, doesn't benefit the development version because it was already done in that version. In the D3D11 version with shadow maps, all triangles must be sent every time as they may be seen in a shadow map (drawn from sun direction viewpoint). So it was impossible in that version to avoid drawing the away-facing triangles. But in the development version there is code to only send one object's triangles to the GPU once each frame, even if it will be used in multiple shadow maps, main view, mirrors and stereoscopic images in that single frame.

But although it doesn't help the development version, we still have the current public version for some months ongoing, so I'm happy if it helps people racing on full grids and the helps the quality of broadcasts by saving a few percent of CPU each frame.

Last edited by Scawen, Sun 11 Feb 2024, 21:05.

Quote from rane_nbg :

I see, tnx for explanation. How much is a hard limit for LOD3 then?

The limit for the physics LOD, whether it is in LOD2 or LOD3, has always been:
Vehicle: points 24 / triangles 42
Object: points 32 / triangles 60

Quote from Eclipsed :

That would start the 2nd wave of mods killing...

There's no mod killing, just a request for people to fix their hacks and help make a good racing / online experience. We don't want to host poorly made lazy mods on our system. There's no need for shoddy work.

Let's not pretend there's something good about people making LOD2 a duplicate of LOD1, or a pointless empty LOD2, or single wheels with more polygons than 9 Raceabouts, or LOD1 with an "export only - do not use" config with half the model deleted, only to cheat the limit.

Last edited by Scawen, Fri 2 Feb 2024, 21:14.

I hope so too. Some of the mods were seriously beyond any reason, I found one that had 65536 triangles per wheel and several with 32000 triangles per wheel.

For reference, the entire Raceabout model (excluding wheels) is 7288 triangles. So 4.5 times that for a single wheel is just silly.

Also quite a few people have abused the LOD system, for example by making LOD2 a straight copy of LOD1 which is really not the spirit, and makes the car take twice as long to generate.

It's pointless, as LOD2 is not actually a requirement. It's possible (and fine for WIP mods) to have only a main LOD and a physics LOD.

Another part of the pitout glitch that will not be fixed at this point, is texture loading. I've worked on that in thew new development version which I want to work on and release. Textures are loaded gradually over the coming frames instead of all at once. So I hope that mod creators will cooperate and do the right thing, so that I have more time available to work on actual development.

WARNING: THIS IS A TEST

THIS DOES NOT CONTAIN NEW TYRE PHYSICS OR THE NEW GRAPHICS SYSTEM

PLEASE TEST BEFORE YOU POST

PLEASE... NO OFF TOPIC FEATURE REQUESTS!


Hello Racers,

Here is a new test patch: 0.7E15

Please read the list of changes below.

0.7E15 is COMPATIBLE with 0.7E

- You CAN connect online with 0.7E
- You CAN play single player replays from 0.7E

You should back up or rename your LFS.exe from version E so you can revert to it if necessary.


Changes in E15:

Improved auto updater and available hosting locations
- New update available is shown on entry screen
- Auto updater page is clearer and simpler to use
- Hosting locations are downloaded instead of hard coded


Changes in E14:

Mark host as favourite and sort by favourites in list of hosts
Sort by server location (two-letter country code) column


Changes in E13:

Improved handling of UDP packets not reaching the host
- List of Hosts comes direct from master server (no pinging)
- You can connect even if host does not receive your UDP packets


Changes in E12:

Cameras:

Small change in calculation of free view camera smoothing
- only intended as preparation for a future change
- slightly more efficient calculation
- should provide identical motion

Multiplayer:

Support for new command to set number of stops completed

Commands:

FIX: Multiple commands now allow more than 1 space between commands

Translations:

More updated translations - Thank you translators!


Changes in E11:

Cameras:

Layout Square cameras now have 40m height instead of 4m
Reduced jiggling of names above cars at extreme zoom
Improved accuracy of camera rotation at extreme zoom

Commands:

/vlock=car/filter/horizon
/lookf=joystick/axis/steer/mouse_x/mouse_xy
/control=mouse_kb/wheel_js


Changes in E10:

FIX: Invert mouse axis did not work in E9


Changes in E9:

Input range improvements:

The full resolution reported by the controller is now supported
- previously drivers were instructed to report -1000 to 1000
- controllers we tested report values 0 to 65535
- so steering wheel moves in smaller steps
The range adjusters in controller options now use percentage values
- the range defaults replicate previously default in-game behaviour
- previously brake/throttle/handbrake/clutch axes had a dead zone
- the dead zones were not adjustable by the user but now are
- the axes visible in game now match the options screen

Support for mod approval:

WIP filter is available on the mod selection screen

Translations:

More translations updated! Thanks to the translators


Changes in E8:

Support for approved mods:

Tick (aka check mark) is shown in mods screen for approved mods
- also TW is shown for tweak mods and padlock for private mods
An 'external link icon' is visible when two columns are displayed
Rating stars pulsate in garage if you have not yet rated the mod

InSim:

NLP/MCI packets are no longer sent after clicking replay slider
- also not sent after IS_RIP unless RIPOPT_FULL_PHYS is set


Changes in E7:

Tightened main model and wheel limits for mod reports
Unlock screen requires "unlock" to keep any changes
(if already unlocked the unlock count is unaffected)
More translation updates. Thank you translators!


Changes in E6:

Optimisations:

Combine rim and spoke object into a single subobject
- saves 4 extra subobject switches for most cars
- update also applies to development version
An optimisation specially for external views
- avoid begin/end scene when drawing env maps/shadows
Tiny opt when drawing driver (avoid some integer maths)
Tiny opt (set projection matrix only once per frame)

Icon:

Fixed icon (old one was copied by mistake in E5 patch)

Translations:

More translation updates, thanks to translators!


Changes in E5:

Mods screen:

New button to show your own mods
Ability to switch on multiple vehicle type filters
New filters for drive type (none/RWD/FWD/AWD)
New sort options power/mass/power-weight ratio
X button beside text filters stops text entry
Updated translations - thanks to translators

Optimisations:

Decreased CPU used when drawing tyres
- reduces CPU used by official GTR cars by around 7%
- smaller optimisation for suspension parts


Changes in E4:

Prevents frequent excess reports for the same mod


Changes in E3:

LOD2 limit detections:

Use true limit of 8192 (which is excessive even if legal)
- LOD2 should really be nearer 1000 triangles (see official cars)
- The check in E2 was extra lenient (as it still is for wheels)
Added check for invisible LOD2 (there is no need for bad LOD2)
- Thread about LOD2: https://www.lfs.net/forum/thread/106736


Changes in E2:

Automatic reporting system for mods with excessive triangles
New command /rtex does a full texture reload from any screen
Some updated translations - thank you translators!

FIX: New steer animation for BF1 stops driver toes protruding
FIX: Minor documentation errors in InSim.txt


INSTALLATION:

Live for Speed LFS 0.7E must already be installed!

To install the patch, download and run the patch installer.

NOTE: You can see if the patch is correctly installed when you run
LFS. Check the version number at the bottom of the entry screen.


DOWNLOAD:

IF YOU ALREADY HAVE 0.7E:
PATCH 0.7E TO 0.7E15 (INSTALLER)
https://www.lfs.net/file_lfs.p ... ATCH_7E_TO_7E15_setup.exe (1.8 MB)

Last edited by Scawen, Wed 3 Jul 2024, 17:40.

I've added that to the RB4, and fixed the triangle errors in XRR / FO8 / XFR / FOX.

I'm nearly at the point to send Eric an update, and I've coded a setup height repair system as these development models have the model object centre correctly located at the lowest point of the model, instead of at rough ground level or whatever other random position they were in the old versions. The repair detects old setup and adjusts height according to a table of height adjustments for the official cars.

That's so all the existing setups will load correctly in the new version. No doubt they'll need an adjustment for the new physics but I think there's no harm in working from old setups.

I think you mean: multiple, selectable wheel styles in a single vehicle.

It's something I'd like to do eventually but it's a big job, cannot be done in a compatible version.

As I keep saying, I'm working on the development version now, not mods (which I've been working on for two years already).


EDIT: OK, apparently I'm losing track of time. Here's a rough history.

We have been working on the new graphics and physics versions for years.
2021 I spent most of the year on mods which we released that year.
2022 was a bit more on mods then back to graphics, multithreading, etc.
2023 I seemed to get pulled back onto mods for most of the year.

The end of 2023 was an unforgettable extreme push on mods so it would be much appreciated if people wouldn't keep asking for big changes to the mods system right now. I can do a few updates here and there to the editor. But my main focus is the new development version.

Last edited by Scawen, Fri 19 Jan 2024, 09:59.

While giving due respect for the pretty mod, it does have a lot of triangles (maxed out in one config and slightly over in the other config) and the wheels exceed the limit.

It's almost exactly the same story as for the N.400S here: https://www.lfs.net/forum/post/2074548#post2074548

Wheels could be made more efficient by using the new rim editor, anyway all the info is in that thread.


EDIT: But I don't believe that making the wheels legal would really sort out the glitch. It should be done, and the new rim editor should be used, and that would help a bit, but I think the maximum number of polygons for the main body is really too high for most computers. Personally I would go for half of the maximum, but I know not many people will agree with me. The RB4 is 2/3 of the maximum.

Another thing on this model, a problem that N.400S does not have - the middle LOD is way too high at 8104 triangles. The maximum is 8192 triangles but middle LODs should really be less than 1000 in my opinion.

One thing I hope is that you will find the pit out glitch is reduced in the new physics and graphics version. I have worked on it. Some of it is spread over more than one frame, especially if you aren't looking at the car at the time. The physical model is built in a physical frame and the graphical model is built when necessary in a graphical frame. Also, in the case of a car that hasn't yet been loaded, and is then loaded the first time since starting LFS, the textures are loaded over multiple frames so that worst of all "first time load" glitch is further reduced.

Last edited by Scawen, Tue 16 Jan 2024, 20:34.

One of the checks recently added to our upload system detects if there is a LOD2 with no polygons in it, and the upload is rejected in that case. This is surprisingly common in submitted mods, although there is no point in this type of configuration.

If you want to submit a mod before you have created a proper LOD2 (for middle distance and shadow) then you should put the physics LOD (which is LOD3 in a properly finished mod) into LOD2.

That is OK for unfinished mods, and you will at least have a shadow and not drive around with a vehicle that is invisible in the middle distance.

FINISHED MOD: (GOOD)
LOD1: Many triangles
LOD2: Medium triangles (e.g. around 1000, see official cars)
LOD3: Physics

UNFINISHED MOD: {OK)
LOD1: Many triangles
LOD2: Physics

WRONG:
LOD1: Many triangles
LOD2: [empty]
LOD3: Physics

EDIT: ALSO WRONG:
LOD1: Many triangles
LOD2: Many triangles, holes, ugly mess
LOD3: Physics

Last edited by Scawen, Fri 2 Feb 2024, 08:53.

Well you can discuss amongst yourselves, but I am only one programmer and I think the priority is completing the new graphics and physics version. Limits were discussed and set long ago. Unfortunately, hackers learned to get around the limits. I've spent the last two years working on improvements for mods, delaying the big release that everyone wants. I worked right up to the limit of my health before the Christmas holidays, to allow me to get back to the main task.

Now I have learned half the mod creators use a hack to bypass the limits, while other people complain about glitches when people leave the pits. My job is to make sure that doesn't happen, then get back to what I am supposed to be working on. The game is supposed to run smoothly and that is the most important thing.

I'm not going to drop what I am working on to continue working on more updates for mods. I hope you understand.

Dear Racers,

We plan to release a new official version this weekend, probably on Sunday.

There's a lot in it, including many improvements for mods. In the new year I will be focussing on the new graphics and physics version, but that is not what this patch is about.

Please test the LFS version now if you can.
LFS Test Patch: https://www.lfs.net/forum/thread/106005

If you are a mod creator, please test the new editor patch.
LFS Editor Test Patch: https://www.lfs.net/forum/thread/106004

You'll see the list of changes is really long. Have a look through the changes if you can!

Or just get the patch and do what you normally do, let us know if there are any problems.

Thanks!

A lot of people would like to use the popup headlights for other purposes. As the patch release is next weekend, I don't have time to do everything that could be done.

But I wondered if it might be possible at least to enable existing light switches to operate moving parts.
E.g. you could use /light rfog/ffog/extra to operate an item if it was set to be connected to that switch.

Keeping it simple at first, that might be, instead of an object type "popup headlight" you would set "rotating object" as the object type then link it to headlights/rfog/ffog/extra.

Now, in my opinion that would already do a lot of what people want, without me having to add extra text commands, user inputs and data sent over multiplayer (in two separate versions of LFS). It's kept simple by using existing switches. So I hope this may be possible in the time available.


But I also wanted to think on a bit further, although this starts to sound too complicated for this week when I already feel under a lot of pressure. The release next weekend is important to me after a very hard work year and I want a fresh start to finish the other version next year, so we can release the new physics, graphics and updated tracks.

Anyway, I couldn't help thinking a bit as I rolled around in bed and had to get up early again and write some things down.

I came up with this.

Types of object:
- rotator [like current headlights, rotates a given amount]
- slider [moves along an axis a given distance]
- spinner [rotates at a given speed]

Rotator and Slider can connect to:
- boolean switches (e.g. light switches)
- axis (e.g. throttle, brake, clutch, steer)

Spinner can connect to:
- boolean switches (e.g. light switches - spins at given speed)
- moving parts (e.g. engine, drive shaft - spins with object or multiple of it)

Well, that's the concept.

Questions remain:

Amounts:

Range of values for "Rotator" amount?
Currently goes from -180 to 180 degrees. Considered enough for popup headlights and probably for most purposes.

Range of values for "Slider" amount?
Given storage limitations, a range of -1000 to 1000 is available. If the resolution is 1mm that would allow movement of 1m. Probably good for many things, but maybe we need an alternative "Large slider" that has resolution of 1cm (allowing movement of up to 10m)

Range of values for "Spinner" amount?
1) When connected to a boolean switch, this would be a set rotation speed (rpm) when connected to a boolean switch. Again, the base value is from -1000 to 1000. Would that be OK if it plainly represented RPM? So you could have a spinning object 1rpm, 2rpm, 3rpm... up to 1000rpm.
2) When connected to a rotating component, it could be a multiple. Usually 1 (e.g. rotate with driveshaft). But maybe 0.5 (e.g. camshafts rotate at half engine speed). Or maybe some things rotate faster than the rotating component? So what sort of range, given again we have -1000 to 1000 but clearly this must be scaled down massively (nothing will rotate at 1000 times the rate of an component it is connected to). Maybe 10 times the speed would do, so it could go from 0.01 up to 10 times the speed of the connected part?

Rotating parts that Spinners could be attached to:

Engine
Drive shaft
Final drive (diff)
Rear (left or right) wheel
Front (left or right) wheel
Steering wheel angle
Steer angle (left or right)

Input axes that Rotator and Sliders could be attached to:

Steering wheel (-1 to 1)
Throttle (0 to 1)
Brake
Clutch
Handbrake

Last edited by Scawen, Sun 10 Dec 2023, 12:24.

Quote from neozixxs :

xrr should be like that ? Great update btw i really like the new features

Oops, I forgot to set the layer correctly so it only appears in the road cars.

Quote from ScammerGamerLOL :

Will there be graphics and night mode in the 0.7E? and how many days left until release?

No, 0.7E has absolutely nothing to do with the new physics and graphics.

0.7E is planned to be released next weekend. It would be really strange to release something we'd been working on for 10 years without even testing it. I've said it a lot of times now. 0.7E allows me to stop working on mods for a while, so finally I can work on finishing the physics and graphics for the really big release.

As said before, it's pretty easy to think of 1000 things that you could say "why on EARTH is THIS feature not done". And let's suppose each of those things take 1 day or a week or a month to do. Assume on average each would take a week. And let's suppose there are 50 weeks a year.

Now we are talking 1000/50 so then in 20 years I could get those things done. And I suppose some people would say... YES! do all those obvious 1000 things, before releasing the new tyre physics and graphics system that has already been coded and that we are waiting for.

But, here's the problem, I do not agree with that. My plan is to release this really big update, 0.7E, with huge amount of mods support, that I have worked nearly every day for a couple of years on, long days, weekends and holidays. And then get back to the new physics and graphics update that I mentioned already. If you don't like that plan, that is your problem really, not mine. As also mentioned, there are other programmers who can write the feature you requested. I've already provided a solution that allows that to be coded. It's called "InSim".

There's only one programmer on the core game, so guess what... I don't have time to write every single peripheral that you could wish for. I did however provide an interface so you can make your own, so why don't you get cracking and sort it out yourself?